1. Field
The present invention relates to failure handling systems, and more particularly, to a failure handling system for handling failure occurring on a network.
2. Description of the Related Art
Ethernet (registered trademark) denotes standards commonly used in LANs (Local Area Networks). While 10BASE-T (10 Mbps) is the most popular one among the standards, recent tendency toward higher-speed transmission has increased demand for standards enabling signal transmission at higher rates, such as Fast Ethernet with a transmission rate of 100 Mbps and Gigabit Ethernet with a transmission rate of 1 Gbps or 10 Gbps.
At the same time, Ethernet fails to meet users' needs in many respects, because of its long failure recovery time and the restrictions on transmission distance. Thus, there has been a trend to adopt the transmission technology of SDH/SONET (Synchronous Digital Hierarchy/Synchronous Optical Network) as a carrier, in order to meet the demand for higher-speed transmission while making up for the drawbacks and also to increase the transmission distance from LAN coverage to WAN (Wide Area Network) coverage.
Ethernet using SDH/SONET as its communication backbone is called EOS (Ethernet over SDH/SONET) and is one of the GFP (Generic Framing Procedure) techniques being standardized by ITU-T G.7041. GFP is a procedure for mapping frames with variable-length payloads, such as Ethernet frames, over SDH/SONET.
FIG. 14 illustrates an EOS network system. The EOS network system 100 comprises client devices 101 and 102, and EOS hosts 111 to 114. The EOS hosts 111 to 114 are included in an SDH network 110.
The client device 101 is connected to the EOS host 111 by client routes R1 and R2, and the EOS hosts 111 and 112 are connected to each other by SDH routes NW1 and NW2. The client device 102 is connected to the EOS host 112 by client routes R3 and R4.
Also, the client device 101 is connected to the EOS host 113 by client routes R5 and R6, and the EOS hosts 113 and 114 are connected to each other by SDH routes NW3 and NW4. The client device 102 is connected to the EOS host 114 by client routes R7 and R8.
When an Ethernet frame is transmitted from the client device 101 to the client device 102, for example, the client device 101 sends the Ethernet frame via the two client routes R1 and R5 to the respective EOS hosts 111 and 113.
The EOS host 111 maps the received Ethernet frame into an SDH frame according to the GFP protocol and sends the SDH frame to the EOS host 112 through the SDH route NW1. The EOS host 112 demaps the received SDH frame to thereby convert the SDH frame back to the Ethernet frame, and sends the Ethernet frame to the client device 102 via the client route R3.
Also, the EOS host 113 maps the received Ethernet frame into an SDH frame according to the GFP protocol and transmits the SDH frame to the EOS host 114 via the SDH route NW3. The EOS host 114 converts the received SDH frame back to the Ethernet frame by demapping, and sends the Ethernet frame to the client device 102 via the client route R7.
Thus, the use of the GFP protocol permits the client devices 101 and 102, each with Ethernet transmission interface function, to communicate Ethernet frames to each other across the SDH network 110.
As conventional GFP transmission techniques, there has been proposed a technique wherein a failure notification region is provided in the transport header of a GFP capsule to transfer information about the occurrence of failure on a transmission line network (e.g., Japanese Unexamined Patent Publication No. 2004-320683 (paragraph nos. [0044] to [0052], FIG. 1)).
Let us consider the case where, in the EOS network system 100 shown in FIG. 14, failure has occurred in the outbound port of the client device 101 connected to the client route R1. In EOS, when failure occurs on the network, devices with the GFP function stop outputting frames to the egress node in accordance with the GFP signal propagation function.
Also, it is assumed that the client device 101 has the function of link aggregation (IEEE 802.3h). The link aggregation is a connection scheme whereby a plurality of physical links can be treated as a single virtual link. By configuring the link aggregation in a span where the bandwidth locally increases, it is possible to cope with local increase in the traffic.
With the link aggregation function, while a certain span is operating normally, frames can be transmitted by using n links, and if m (<n) links become unavailable, frames are transmitted by using (n−m) links (the bandwidth decreases correspondingly, compared with the case of using n links).
FIG. 15 illustrates a case where failure has occurred while the link aggregation function is performed. If failure occurs in the client route R1 as illustrated, the EOS host 112 recognizes that failure has occurred on the originating side, because the input of frames from the EOS host 111 stops, and thus discontinues outputting frames to the client route R3 (shutoff control).
Also, since the input of frames from the client route R3 stops, the client device 102 recognizes that failure has occurred on the originating side, and switches the receiving mode from dual-route reception via the client routes R3 and R7, executed until the occurrence of failure, to single-route reception via the client route R7 only.
Further, on detecting the failure of the client route R1, the client device 101 exercises the link aggregation and redundancy function so that Ethernet frames, which had been output to both the client routes R1 and R5 before the occurrence of the failure, may be output only to the client route R5 (the transmission bandwidth reduces by half, compared with the dual-route output). The process described above enables the communication to be continued even in the event failure occurs on the part of the client device 101 or 102.
Let us now consider the case where failure has occurred in the SDH route NW1 within the SDH network 110. In the following, SDH is taken as an example, but the same applies to SONET. FIG. 16 illustrates the case where failure has occurred in the SDH network 110. If the SDH route NW1 fails, the EOS host 112 detects the failure and stops outputting SDH frames to the client route R3 (shutoff control), thus enabling the client device 102 to recognize that failure has occurred on the originating side.
However, the GFP signal propagation function does not allow the EOS host 112 to notify the EOS host 111 of SDH failure, so that the EOS host 111 is unable to control the output of the client device 101, giving rise to a problem that the client device 101 keeps outputting Ethernet frames uselessly. Also, since the client device 101 is unaware of the failure, the link aggregation function fails to be exercised.
Further, if in this state the EOS host 112, which has detected the SDH failure, shuts off the input thereto from the client route R4, communication deadlock takes place, making the communication irrecoverable.
Furthermore, consider a case where RDI-P which is an alarm of SDH failure to an upstream side is used to perform shutoff control. Since RDI-P is always detected in SDH one-way transmission (one-way communication) (in one-way communication, UNEQ-P is transferred at an ADD station, and RDI-P is transferred at a DROP station which receives the UNEQ-P), this case has a problem that RDI-P cannot be used as a condition for the shutoff control. (ITU-T G783: Occurrence conditions of PDI-P: AIS-P, LOP-P, LOM, PLM-P, TIM-P, UNEQ-P)
Thus, in the conventional EOS network system, where an SDH route in the SDH network has failed, the receiving client device for which Ethernet frames are destined can be notified of the failure by virtue of the GFP shutoff control, but the originating client device from which the Ethernet frames are originated is unable to recognize the failure, giving rise to a problem that the originating client device keeps outputting Ethernet frames.